Skip to content

crypto/tls: use Go's software TLS on the host target - #5645

Closed
0pcom wants to merge 1 commit into
tinygo-org:devfrom
0magnet:crypto-tls-host
Closed

crypto/tls: use Go's software TLS on the host target#5645
0pcom wants to merge 1 commit into
tinygo-org:devfrom
0magnet:crypto-tls-host

Conversation

@0pcom

@0pcom 0pcom commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

TinyGo's crypto/tls is a thin wrapper around a netdev-provided (hardware/firmware-offloaded) TLS socket, which only exists on the embedded/wasm targets that have such a netdev. On the host/native target the netdev is raw syscalls with no TLS offload, so crypto/tls could never actually work there. Link Go's full software crypto/tls on the host instead, keyed off needsSyscallPackage (true exactly for the embedded/wasm targets, which keep the offload wrapper unchanged).

Go's crypto/tls needs one runtime hook TinyGo lacked: weak.runtime_makeStrongFromWeak (Go 1.24 weak pointers). Added next to the existing registerWeakPointer as a strong-reference no-op — weak pointers are never collected here, so the referent is always alive.

Verified on linux/amd64 (LLVM 22): a real TLS 1.3 handshake and HTTPS round trip entirely in-process — tls.Client against an http.Server behind a TLS listener over loopback — plus external curl -k against the same server. Pairs with tinygo-org/net#79 (net/http.ListenAndServeTLS/ServeTLS), but is independently useful for any crypto/tls client use.

🤖 Generated with Claude Code

https://claude.ai/code/session_01C3X3gvq8ZggMRvzVzWm66i

TinyGo's crypto/tls is a thin wrapper around a netdev-provided
(hardware/firmware-offloaded) TLS socket, which only exists on the
embedded/wasm targets that have such a netdev. On the host/native target
the netdev is raw syscalls with no TLS offload, so crypto/tls could
never actually work there. Link Go's full software crypto/tls on the
host instead, keyed off needsSyscallPackage, which is true exactly for
the embedded/wasm targets.

Go's crypto/tls needs one runtime hook TinyGo lacked:
weak.runtime_makeStrongFromWeak (Go 1.24 weak pointers). Add it next to
the existing registerWeakPointer as a strong-reference no-op (weak
pointers are never collected here, so the referent is always alive).
@yohimik

yohimik commented Sep 5, 2026

Copy link
Copy Markdown

This overlaps #5633 for the weak hook and #5635 for hosted software TLS. I am removing the copied weak commit from #5635 so that each change has one patch in our series. Could we use #5633 for the hook and agree on one loader PR? #5635 includes loader target-selection tests and a handshake test that rejects an unknown CA. Its selection is limited to hosted Linux and Darwin. This PR uses needsSyscallPackage, which also selects other hosted targets, so the two guards need a target-by-target check before consolidation. The tests and downstream client evidence in #5635 are available for either approach. I will not change your branch.

@0pcom

0pcom commented Sep 5, 2026

Copy link
Copy Markdown
Contributor Author

Agreed on both counts. #5633 carries the weak hook — it was first and it is the single home for that change.

On the loader guard: you are right that they are not equivalent. needsSyscallPackage selects every hosted target, which would switch on software TLS for hosted windows too, and nobody has tested a handshake there. Your explicit linux/darwin selection in #5635 is the right starting point — widening to other hosted targets can be its own change once one of us has actually run it there. #5635 also already has the target-selection tests and the unknown-CA rejection test, which this branch does not.

So: closing this in favor of #5633 + #5635. If anything from this branch is useful when consolidating (the needsSyscallPackage route is preserved here for reference), take it freely.

@0pcom 0pcom closed this Sep 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants